<html>
<head>
<title>KML - Keyhole Markup Language</title>
</head>

<body bgcolor="#ffffff">

<h1>KML - Keyhole Markup Language</h1>

<p>Keyhole Markup Language (KML) is an XML-based language for managing the display of 3D geospatial data. 
KML has been accepted as an OGC standard, and is supported in one way or another
on the major GeoBrowsers. 
Note that KML by specification uses only a single projection, EPSG:4326. All OGR KML output will be 
presented in EPSG:4326. As such OGR will create layers in the correct coordinate system and transform 
any geometries.</p>

<p>At this time, only vector layers are handled by the KML driver. <em>(there are additional scripts
supplied with the GDAL project that can build other kinds of output)</em></p>

<h3>KML Reading</h3>
<p>KML reading is only available if GDAL/OGR is built with the Expat XML Parser, otherwise only KML writing will be supported.</p>

<p>  Supported geometry types are <code>Point</code>, <code>Linestring</code>, <code>Polygon</code>, <code>MultiPoint</code>,
<code>MultiLineString</code>, <code>MultiPolygon</code> and <code>MultiGeometry</code>. There are limitations,
for example: the nested nature of folders in a source KML file is lost; folder <code>&lt;description&gt;</code> tags will
not carry through to ouput. Since GDAL 1.6.1, folders containing multiple geometry types, like POINT and POLYGON, are supported.</p>

<h3>KML Writing</h3>
<p>Since not all features of KML
are able to be represented in the Simple Features geometry model, you will not be able to generate
many KML-specific attributes from within GDAL/OGR. Please try
a few test files to get a sense of what is possible.</p>

<p>When outputting KML, the OGR KML driver will translate each OGR Layer into a KML Folder
(you may encounter unexpected behavior
if you try to mix the geometry types of elements in a layer, e.g. <code>LINESTRING</code> and
<code>POINT</code> data).</p>

<p>The KML Driver will rename some layers, or source KML folder names, into new names
it considers valid, for example '<code>Layer #0</code>', the default name of the first unnamed
Layer, becomes <code>'Layer__0'</code>.</p>


<p>KML is mix of formatting and feature data. The &lt;description&gt; tag of a Placemark will 
be displayed in most geobrowsers as an HTML-filled balloon. When writing KML, Layer element
attributes are added as simple schema fields. This best preserves feature type information.</p>
<p>Limited support is available for fills, line color and other styling attributes. Please try a few sample
files to get a better sense of actual behavior.</p>

<h3>Encoding issues</h3>

Expat library supports reading the following built-in encodings :
<ul>
<li>US-ASCII</li>
<li>UTF-8</li>
<li>UTF-16</li>
<li>ISO-8859-1</li>
</ul>

OGR 1.8.0 adds supports for Windows-1252 encoding (for previous versions, altering the encoding
mentionned in the XML header to ISO-8859-1 might work in some cases).<p>

The content returned by OGR will be encoded in UTF-8, after the conversion from the
encoding mentionned in the file header is.<p>

If your KML file is not encoded in one of the previous encodings, it will not be parsed by the
KML driver. You may convert it into one of the supported encoding with the <i>iconv</i> utility
for example and change accordingly the <i>encoding</i> parameter value in the XML header.<br>
<p>

When writing a KML file, the driver expects UTF-8 content to be passed in.<p>

<h3>Creation Options</h3>
<p>The following dataset creation options are supported:
<ul>
<li><b>NameField</b>: Allows you to specify the field to use for the KML &lt;name&gt; element. Default value : 'Name'</li>
<pre>ogr2ogr -f KML output.kml input.shp -dsco NameField=RegionName</pre>
<li><b>DescriptionField</b>: Allows you to specify the field to use for the KML &lt;description&gt; element. Default value : 'Description'</li>
</li>
<li><b>AltitudeMode</b>: Allows you to specify the AltitudeMode to use for KML geometries. This will only affect 3D geometries   
and must be one of the valid KML options.  
See the <a href="http://code.google.com/apis/kml/documentation/kml_tags_21.html#altitudemode">relevant KML reference material</a>  
for further information. 
<pre>ogr2ogr -f KML output.kml input.shp -dsco AltitudeMode=absolute</pre>
</li>  
</ul>


<h2>VSI Virtual File System API support</h2>

(Some features below might require OGR >= 1.9.0)<p>

The driver supports reading and writing to files managed by VSI Virtual File System API, which include
"regular" files, as well as files in the /vsizip/ (read-write) , /vsigzip/ (read-write) , /vsicurl/ (read-only) domains.<p>

Writing to /dev/stdout or /vsistdout/ is also supported.<p>

<h2>Example</h2>
The ogr2ogr utility can be used to dump the results of a PostGIS query to
KML:

<pre>
ogr2ogr -f KML output.kml PG:'host=myserver dbname=warmerda' -sql "SELECT pop_1994 from canada where province_name = 'Alberta'"
</pre>
</p>

<p>How to dump contents of .kml file as OGR sees it:
<pre>
ogrinfo -ro somedisplay.kml
</pre>
</p>
<h2>Caveats</h2>
<p>
Google Earth seems to have some limits regarding the number of coordinates in complex geometries like polygons.
If the problem appears, then problematic geometries are displayed completely or partially covered by vertical stripes.
Unfortunately, there are no exact number given in the KML specification about this limitation, so the KML driver
will not warn about potential problems. One of possible and tested solutions is to simplify a line or a polygon to remove
some coordinates.
Here is the whole discussion about this issue on the <a href="http://groups.google.com/group/kml-support">Google KML Developer Forum</a>, in the <a href="http://groups.google.com/group/kml-support-getting-started/browse_thread/thread/e6995b8073e69c41">polygon displays with vertical stripes</a> thread.
</p>

<h2>See Also</h2>
<ul>
<li> <a href="https://developers.google.com/kml/?csw=1">KML Specification</a></li>
<li> <a href="https://developers.google.com/kml/documentation/kml_tut">KML Tutorial</a></li>
</ul>

</body>
</html>
